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DETAILED ACTION 
Claim Rejections - 35 USC § 102 

1 . The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1 ) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

2. Claims 1-4, 8, 9, 20 rejected under 35 U.S.C. 102(e) as being anticipated by 
US 6769116 to Sexton. 

3. Referring to claim 1 , Sexton discloses an apparatus comprising: an analysis 
block configured to generate debug information in response to (i) a command input 
(From line 15 of column 8, "To debug memory corruption, a predetermined pointer is set 
to the desired address, which is checked in the instrumented memory management 
routines, and a breakpoint is set on the breakpointable function. Thus, the execution of 
large portions of the program can be quickly passed over before starting the intensive 
watchpointing or other memory inspection procedure."), (ii) one or more simulation 
outputs (From line 43 of column 8 (with emphasis), "Preferably, the instrumented code 
is conditionally compiled into the program. Thus, the development version of the 
program would include the instrumented code, but the production version of the 
program need not include the instrumented code."), and (iii) one or more compiler 
outputs (From line 43 of column 8 (with emphasis), "Preferably, the instrumented code 
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is conditionally compiled into the program. Thus, the development version of the 
program would include the instrumented code, but the production version of the 
program need not include the instrumented code."); 

a graphical user interface (From line 55 of column 5, "Computer system 100 may 
be coupled via bus 102 to a display 112, such as a cathode ray tube (CRT), for 
displaying information to a computer user. An input device 114, including alphanumeric 
and other keys, is coupled to bus 102 for communicating information and command 
selections to processor 104. Another type of user input device is cursor control 116, 
such as a mouse, a trackball, or cursor direction keys for communicating direction 
information and command selections to processor 104 and for controlling cursor 
movement on display 1 12. This input device typically has two degrees of freedom in two 
axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify 
positions in a plane." From line 55 of column 8, "When the instrumented code have 
been compiled into memory management or other library routines of the program under 
a debugging switch, the programmer is now ready to diagnose the cause of the memory 
corruption. Preferably, the following steps are performed within a symbolic debugger 
such as sdb (a standard UNIX.TM. debugger) or gdb (a freeware debugger), but some 
of the steps may optionally be performed by hard coding some additional code into the 
program and recompiling.") configured (i) to present said command input in response to 
one or more user input parameters and (ii) to display said debug information (From line 
31 of column 8, "If equal, the memory allocation routine would then call a debugging 
function. The debugging function need not do anything at all and can be a stub function 
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that merely returns back to the calling function as long as the debugging function allows 
for a breakpoint to be set in the debugger. In some embodiments, however, the 
debugging function can also output useful information, such as the address, type, and 
value of the object to the screen or to a log file. In addition, a separate debugging 
routine may be provided for each of the memory management routines." From line 10 of 
column 9, "When the breakpoint is triggered (e.g. when a memory management routine 
handles an object with the address set in the global debug pointer), the debugger 
breaks execution of the problem, allowing the programmer to issue debugging 
commands to inspect memory locations and continue the program's running from the 
breakpoint. For example, when the memory allocation routine allocates memory for an 
object that starts with the address set in the global debug pointer, then the debugging 
routine would be called, triggering the breakpoint and suspending execution of the 
program within the debugger."); and 

a memory circuit configured to store said one or more simulation outputs and 
said one or more compiler outputs (From column 5, RAM, ROM. From column 6, 
computer-readable medium. From column 7, virtual memory, secondary storage.). 
4. Referring to claim 2, Sexton discloses said one or more user input parameters 
comprise identification of a memory address (From line 15 of column 8, "To debug 
memory corruption, a predetermined pointer is set to the desired address, which is 
checked in the instrumented memory management routines, and a breakpoint is set on 
the breakpointable function. Thus, the execution of large portions of the program can be 
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quickly passed over before starting the intensive watchpointing or other memory 
inspection procedure."). 

5. Referring to claim 3, Sexton discloses said one or more user input parameters 
comprise identification of specific memory accesses (From line 30 of column 9, "At 
block 208, e.g. after the last breakpoint is triggered, a watchpoint is set to detect 
changes to the memory location that is being corrupted. Alternatively, the memory 
location can be manually inspected by single stepping through the program. After 
setting the watchpoint, execution of the program is continued until the watchpoint is 
triggered, which occurs upon a change to the corrupted memory location, thereby 
breaking execution of the program. At each of the breaks in execution due to 
encountering the watchpoints, the programmer can use the debugger to inspect the 
program and data in search of the cause of the memory corruption. If the programmer 
does indeed concluded that the latest watchpoint detected the actual corruption, rather 
than an intended use of the memory location, then the programmer can tell from the 
current program counter in the debugger which statement caused the corruption."). 

6. Referring to claim 4, Sexton discloses said one or more user input parameters 
comprise one or more of a command for expanding the display of a memory map, a 
command for retrieving information related to accesses to said memory map, a 
command for retrieving assembly code related to particular accesses and one or more 
commands related to filtering operations (At least, from line 30 of column 9, "At block 
208, e.g. after the last breakpoint is triggered, a watchpoint is set to detect changes to 
the memory location that is being corrupted. Alternatively, the memory location can be 
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manually inspected by single stepping through the program. After setting the 
watchpoint, execution of the program is continued until the watchpoint is triggered, 
which occurs upon a change to the corrupted memory location, thereby breaking 
execution of the program. At each of the breaks in execution due to encountering the 
watchpoints, the programmer can use the debugger to inspect the program and data in 
search of the cause of the memory corruption. If the programmer does indeed 
concluded that the latest watchpoint detected the actual corruption, rather than an 
intended use of the memory location, then the programmer can tell from the current 
program counter in the debugger which statement caused the corruption."). 

7. Referring to claim 8, Sexton discloses said one or more user input parameters 
are entered using one or more of a mouse, a keyboard, a touch screen and voice 
recognition (From line 55 of column 5, "Computer system 100 may be coupled via bus 
102 to a display 112, such as a cathode ray tube (CRT), for displaying information to a 
computer user. An input device 114, including alphanumeric and other keys, is coupled 
to bus 102 for communicating information and command selections to processor 104. 
Another type of user input device is cursor control 1 1 6, such as a mouse, a trackball, or 
cursor direction keys for communicating direction information and command selections 
to processor 104 and for controlling cursor movement on display 112. This input device 
typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis 
(e.g., y), that allows the device to specify positions in a plane." ). 

8. Referring to claim 9, Sexton discloses said graphic user interface is configured to 
provide an indication of receipt of said user input parameters (Wherein, at least, in 
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Sexton, something happens as a result of the programmer graphically using the 
interface, e.g., the invention of Sexton.). 

9. Referring to claim 20, Sexton discloses means for identifying a memory address 
in a user defined memory map (From line 9 of column 4, "To use these instrumented 
memory management routines, a programmer ascertains the address of the object that 
was corrupted, typically by inspecting the core dump, and sets the global pointer to that 
address." From line 15 of column 8, "To debug memory corruption, a predetermined 
pointer is set to the desired address, which is checked in the instrumented memory 
management routines, and a breakpoint is set on the breakpointable function. Thus, the 
execution of large portions of the program can be quickly passed over before starting 
the intensive watchpointing or other memory inspection procedure." Wherein the user is 
the programmer, the memory mapping is programmed, directly or indirectly, by the 
programmer.); 

means for retrieving one or more accesses related to an identified memory 
address from simulation results; (C) identifying a specific one of said one or more 
accesses to be examined (From line 10 of column 9, "When the breakpoint is triggered 
(e.g. when a memory management routine handles an object with the address set in the 
global debug pointer), the debugger breaks execution of the problem, allowing the 
prograrhmer to issue debugging commands to inspect memory locations and continue 
the program's running from the breakpoint. For example, when the memory allocation 
routine allocates memory for an object that starts with the address set in the global 
debug pointer, then the debugging routine would be called, triggering the breakpoint 
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and suspending execution of the program within the debugger." From line 43 of column 
8 (with emphasis), "Preferably, the instrumented code is conditionally compiled into the 
program. Thus, the development version of the program would include the 
instrumented code, but the production version of the program need not include the 
instrumented code."); and 

means for retrieving one or more types of debug information related to said 
specific access from said simulation results (From line 31 of column 8, "If equal, the 
memory allocation routine would then call a debugging function. The debugging function 
need not do anything at all and can be a stub function that merely returns back to the 
calling function as long as the debugging function allows for a breakpoint to be set in the 
debugger. In some embodiments, however, the debugging function can also output 
useful information, such as the address, type, and value of the object to the screen or to 
a log file. In addition, a separate debugging routine may be provided for each of the 
memory management routines." From line 30 of column 9, "At block 208, e.g. after the 
last breakpoint is triggered, a watchpoint is set to detect changes to the memory 
location that is being corrupted. Alternatively, the memory location can be manually 
inspected by single stepping through the program. After setting the watchpoint, 
execution of the program is continued until the watchpoint is triggered, which occurs 
upon a change to the corrupted memory location, thereby breaking execution of the 
program. At each of the breaks in execution due to encountering the watchpoints, the 
programmer can use the debugger to inspect the program and data in search of the 
cause of the memory corruption. If the programmer does indeed concluded that the 



Application/Control Number: 1 0/706, 1 27 Page 9 

Art Unit: 21 14 

latest watchpoint detected the actual corruption, rather than an intended use of the 
memory location, then the programmer can tell from the current program counter in the 
debugger which statement caused the corruption."). 

Claim Rejections - 35 USC § 103 

10. Claim 5 rejected under 35 U.S.C. 103(a) as being unpatentable over US 
6769116 to Sexton as applied to claim 1 above, and further in view of US 6052524 
to Pauna. 

1 1 . Referring to claim 5, although Sexton does not specifically disclose that said one 
or more simulation outputs comprise information from one or more of a processor 
simulator and one or more processor simulation models, using a hardware simulator in 
conjunction with software debugging is known in the art. An example of this is shown by 
Pauna, from the abstract, "A system and methods are provided to design, verify and 
develop simulated hardware and software components for a desired electrical device." 
A person of ordinary skill in the art at the time of the invention would have been 
motivated to perform hardware software co-simulation because from line 6 of column 2 
of Pauna, "In today's world, "co-verification" using simulation technologies allows 
developers to design and verify the behavior of hardware and software components in a 
new electronic device. Behavior of hardware and software components can be 
examined during a simulation by setting break-points, stopping the simulation at various 
states, and examining data generated by the simulation. Various simulations also allow 
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certain hardware components to be emulated with a hardware description language 
while other hardware and software components are simulated." 

12. Claims 6, 7 rejected under 35 U.S.C. 103(a) as being unpatentable over US 
6769116 to Sexton as applied to claim 1 above, and further in view of "frames" 
and "windows". 

13. Referring to claims 6, 7, although Sexton does not specifically disclose said 
graphical user interface is configured to present said debug information in one or more 
windows or frames, these are very well known in the art. Examiner takes official notice4 
for "windows" and "frames". A person of ordinary skill in the art at the time of the 
invention would have been motivated to use windows or frames to display data because 
windows and frames, particularly in a GUI environment serve to graphically partition 
data for display to a user. 

14. Claim 10, 12, 14-19 rejected under 35 U.S.C. 103(a) as being unpatentable 
over US 6769116 to Sexton in view of US 6052524 to Pauna. 

15. Referring to claim 10, Sexton discloses (A) identifying a memory address to be 
examined (From line 9 of column 4, "To use these instrumented memory management 
routines, a programmer ascertains the address of the object that was corrupted, 
typically by inspecting the core dump, and sets the global pointer to that address." From 
line 15 of column 8, "To debug memory corruption, a predetermined pointer is set to the 
desired address, which is checked in the instrumented memory management routines, 
and a breakpoint is set on the breakpointable function. Thus, the execution of large 
portions of the program can be quickly passed over before starting the intensive 
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watchpointing or other memory inspection procedure."); 

(B) retrieving one or more accesses related to said memory address; (C) 
identifying a specific one of said one or more accesses to be examined (From line 10 of 
column 9, "When the breakpoint is triggered (e.g. when a memory management routine 
handles an object with the address set in the global debug pointer), the debugger 
breaks execution of the problem, allowing the programmer to issue debugging 
commands to inspect memory locations and continue the program's running from the 
breakpoint. For example, when the memory allocation routine allocates memory for an 
object that starts with the address set in the global debug pointer, then the debugging 
routine would be called, triggering the breakpoint and suspending execution of the 
program within the debugger."); and 

(D) retrieving one or more types of debug information related to said identified 
access (From line 31 of column 8, "If equal, the memory allocation routine would then 
call a debugging function. The debugging function need not do anything at all and can 
be a stub function that merely returns back to the calling function as long as the 
debugging function allows for a breakpoint to be set in the debugger. In some 
embodiments, however, the debugging function can also output useful information, such 
as the address, type, and value of the object to the screen or to a log file. In addition, a 
separate debugging routine may be provided for each of the memory management 
routines." From line 30 of column 9, "At block 208, e.g. after the last breakpoint is 
triggered, a watchpoint is set to detect changes to the memory location that is being 
corrupted. Alternatively, the memory location can be manually inspected by single 
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stepping through the program. After setting the watchpoint, execution of the program is 
continued until the watchpoint is triggered, which occurs upon a change to the corrupted 
memory location, thereby breaking execution of the program. At each of the breaks in 
execution due to encountering the watchpoints, the programmer can use the debugger 
to inspect the program and data in search of the cause of the memory corruption. If the 
programmer does indeed concluded that the latest watchpoint detected the actual 
corruption,. rather than an intended use of the memory location, then the programmer 
can tell from the current program counter in the debugger which statement caused the 
corruption."). 

Although Sexton does not specifically disclose debugging RTL simulations of 
processor based system on chip (SoC), using a SoC simulator in conjunction with 
software debugging is known in the art. An example of this is shown by Pauna, from the 
abstract, "A system and methods are provided to design, verify and develop simulated 
hardware and software components for a desired electrical device." Further, from line 
52 of column 1 of Pauna, "As electronic device development became increasing 
complex, very few hardware components of the system were built without performing a 
design verification first. The design verification was used to confirm that hardware 
components result in a design that operates in accordance with predetermined 
functional specifications. Hardware Description Languages ("HDLs") were developed to 
emulate and verify the design of hardware components. Hardware description 
languages known in the art include Very High Speed Integrated Circuit Hardware 
Description Language ("VHSIC HDL" or "VHDL")), Programming Control Language 
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("PCL") and others. Hardware description languages provide a gate-level emulation of 
hardware devices. For more information on VHDL, see Institute of Electrical and 
Electronic Engineers ("IEEE") standard 1076, which is incorporated herein by reference. 
Hardware description languages generally include a set of instructions for sending and 
receiving data to an emulated device under test, storing and receiving data, and other 
interactions. This allows the behavior of a proposed hardware device to be verified 
before it is built." Further, from line 50 of column 4 (with emphasis), "The system further 
includes a simulator library for modeling and verifying hardware components of a 
desired electronic device. The simulator library may include built-in models for 
simulating multiple internal and external hardware components (e.g., central processing 
units, memory, memory management units, caches, timers, universal asynchronous 
receiver transmitters and digital signal processors). The built-in models return a number 
of cycles on the cycle-accurate simulator executed for a desired simulated operation. 
The simulator library may also include simulator interface routines for setting a clock for 
a simulated component to a new clock speed, coordinating between a simulator library 
clock and a cycle-accurate simulator clock, handling events that occur before or during 
a current clock cycle, changing interrupt vectors and interrupt priority levels, providing 
notification of changes in registers during a simulated operation, or for setting one 
or more individual sub-components (e.g., status bits) of a simulated hardware 
component. The simulator library with built-in models and routines is used as an 
interface to the cycle-accurate simulator." A person of ordinary skill in the art at the time 
of the invention would have been motivated to perform hardware software co-simulation 
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because from line 6 of column 2 of Pauna, "In today's world, "co-verification" using 
simulation technologies allows developers to design and verify the behavior of hardware 
and software components in a new electronic device. Behavior of hardware and 
software components can be examined during a simulation by setting break-points, 
stopping the simulation at various states, and examining data generated by the 
simulation. Various simulations also allow certain hardware components to be emulated 
with a hardware description language while other hardware and software components 
are simulated." 

16. Referring to claim 12, Sexton in view of Pauna discloses said one or more types 
of debug information comprise a register status of said processor (From line 65 of 
column 4 of Pauna, "providing notification of changes in registers during a simulated 
operation". Sexton, from line 31 of column 8, "If equal, the memory allocation routine 
would then call a debugging function. The debugging function need not do anything at 
all and can be a stub function that merely returns back to the calling function as long as 
the debugging function allows for a breakpoint to be set in the debugger. In some 
embodiments, however, the debugging function can also output useful information, such 
as the address, type, and value of the object to the screen or to a log file. In addition, a 
separate debugging routine may be provided for each of the memory management 
routines." Sexton, from line 30 of column 9, "At block 208, e.g. after the last breakpoint 
is triggered, a watchpoint is set to detect changes to the memory location that is being 
corrupted. Alternatively, the memory location can be manually inspected by single 
stepping through the program. After setting the watchpoint, execution of the program is 
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continued until the watchpoint is triggered, which occurs upon a change to the corrupted 
memory location, thereby breaking execution of the program. At each of the breaks in 
execution due to encountering the watchpoints, the programmer can use the debugger 
to inspect the program and data in search of the cause of the memory corruption. If the 
programmer does indeed concluded that the latest watchpoint detected the actual 
corruption, rather than an intended use of the memory location, then the programmer 
can tell from the current program counter in the debugger which statement caused the 
corruption."). 

17. Referring to claim 14, Sexton discloses said one or more types of debug 
information comprise a program structure (From line 31 of column 8, "If equal, the 
memory allocation routine would then call a debugging function. The debugging function 
need not do anything at all and can be a stub function that merely returns back to the 
calling function as long as the debugging function allows for a breakpoint to be set in the 
debugger. In some embodiments, however, the debugging function can also output 
useful information, such as the address, type, and value of the object to the screen or to 
a log file. In addition, a separate debugging routine may be provided for each of the 
memory management routines." From line 30 of column 9, "At block 208, e.g. after the 
last breakpoint is triggered, a watchpoint is set to detect changes to the memory 
location that is being corrupted. Alternatively, the memory location can be manually 
inspected by single stepping through the program. After setting the watchpoint, 
execution of the program is continued until the watchpoint is triggered, which occurs 
upon a change to the corrupted memory location, thereby breaking execution of the 
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program. At each of the breaks in execution due to encountering the watchpoints, the 
programmer can use the debugger to inspect the program and data in search of the 
cause of the memory corruption. If the programmer does indeed concluded that the 
latest watchpoint detected the actual corruption, rather than an intended use of the 
memory location, then the programmer can tell from the current program counter in the 
debugger which statement caused the corruption."). 

18. Referring to claim 15, Sexton discloses retrieving one or more accesses related 
to said memory address comprises: responding to activation of a button presented by a 
graphic user interface (From line 55 of column 5, "Computer system 100 may be 
coupled via bus 102 to a display 112, such as a cathode ray tube (CRT), for displaying 
information to a computer user. An input device 114, including alphanumeric and other 
keys, is coupled to bus 102 for communicating information and command selections to 
processor 104. Another type of user input device is cursor control 116, such as a 
mouse, a trackball, or cursor direction keys for communicating direction information and 
command selections to processor 104 and for controlling cursor movement on display 
112. This input device typically has two degrees of freedom in two axes, a first axis 
(e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a 
plane." From line 55 of column 8, "When the instrumented code have been compiled 
into memory management or other library routines of the program under a debugging 
switch, the programmer is now ready to diagnose the cause of the memory corruption. 
Preferably, the following steps are performed within a symbolic debugger such as sdb 
(a standard UNIX.TM. debugger) or gdb (a freeware debugger), but some of the steps 
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may optionally be performed by hard coding some additional code into the program and 
recompiling.") configured (i) to present said command input in response to one or more 
user input parameters and (ii) to display said debug information (From line 31 of column 
8, "If equal, the memory allocation routine would then call a debugging function. The 
debugging function need not do anything at all and can be a stub function that merely 
returns back to the calling function as long as the debugging function allows for a 
breakpoint to be set in the debugger. In some embodiments, however, the debugging 
function can also output useful information, such as the address, type, and value of the 
object to the screen or to a log file. In addition, a separate debugging routine may be 
provided for each of the memory management routines." From line 10 of column 9, 
"When the breakpoint is triggered (e.g. when a memory management routine handles 
an object with the address set in the global debug pointer), the debugger breaks 
execution of the problem, allowing the programmer to issue debugging commands to 
inspect memory locations and continue the program's running from the breakpoint. For 
example, when the memory allocation routine allocates memory for an object that starts 
with the address set in the global debug pointer, then the debugging routine would be 
called, triggering the breakpoint and suspending execution of the program within the 
debugger."). 

1 9. Referring to claim 1 6, Sexton discloses identifying a specific access is performed 
via a graphic user interface (From line 55 of column 5, "Computer system 100 may be 
coupled via bus 102 to a display 112, such as a cathode ray tube (CRT), for displaying 
information to a computer user. An input device 114, including alphanumeric and other 
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keys, is coupled to bus 102 for communicating information and command selections to 
processor 104. Another type of user input device is cursor control 116, such as a 
mouse, a trackball, or cursor direction keys for communicating direction information and 
command selections to processor 104 and for controlling cursor movement on display 
112. This input device typically has two degrees of freedom in two axes, a first axis 
(e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a 
plane." From line 55 of column 8, "When the instrumented code have been compiled 
into memory management or other library routines of the program under a debugging 
switch, the programmer is now ready to diagnose the cause of the memory corruption. 
Preferably, the following steps are performed within a symbolic debugger such as sdb 
(a standard UNIX.TM. debugger) or gdb (a freeware debugger), but some of the steps 
may optionally be performed by hard coding some additional code into the program and 
recompiling.") configured (i) to present said command input in response to one or more 
user input parameters and (ii) to display said debug information (From line 31 of column 
8, "If equal, the memory allocation routine would then call a debugging function. The 
debugging function need not do anything at all and can be a stub function that merely 
returns back to the calling function as long as the debugging function allows for a 
breakpoint to be set in the debugger. In some embodiments, however, the debugging 
function can also output useful information, such as the address, type, and value of the 
object to the screen or to a log file. In addition, a separate debugging routine may be 
provided for each of the memory management routines." From line 10 of column 9, 
"When the breakpoint is triggered (e.g. when a memory management routine handles 
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an object with the address set in the global debug pointer), the debugger breaks 
execution of the problem, allowing the programmer to issue debugging commands to 
inspect memory locations and continue the program's running from the breakpoint. For 
example, when the memory allocation routine allocates memory for an object that starts 
with the address set in the global debug pointer, then the debugging routine would be 
called, triggering the breakpoint and suspending execution of the program within the 
debugger." From line 31 of column 8, "If equal, the memory allocation routine would 
then call a debugging function. The debugging function need not do anything at all and 
can be a stub function that merely returns back to the calling function as long as the 
debugging function allows for a breakpoint to be set in the debugger. In some 
embodiments, however, the debugging function can also output useful information, such 
as the address, type, and value of the object to the screen or to a log file. In addition, a 
separate debugging routine may be provided for each of the memory management 
routines." From line 30 of column 9, "At block 208, e.g. after the last breakpoint is 
triggered, a watchpoint is set to detect changes to the memory location that is being 
corrupted. Alternatively, the memory location can be manually inspected by single 
stepping through the program. After setting the watchpoint, execution of the program is 
continued until the watchpoint is triggered, which occurs upon a change to the corrupted 
memory location, thereby breaking execution of the program. At each of the breaks in 
execution due to encountering the watchpoints, the programmer can use the debugger 
to inspect the program and data in search of the cause of the memory corruption. If the 
programmer does indeed concluded that the latest watchpoint detected the actual 
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corruption, rather than an intended use of the memory location, then the programmer 
can tell from the current program counter in the debugger which statement caused the 
corruption."). 

20. Referring to claim 1 7, Sexton discloses retrieving one or more types of debug 
information is performed in response to a button of a graphic user interface being 
actuated (From line 55 of column 5, "Computer system 100 may be coupled via bus 102 
to a display 112, such as a cathode ray tube (CRT), for displaying information to a 
computer user. An input device 1 14, including alphanumeric and other keys, is coupled 
to bus 102 for communicating information and command selections to processor 104. 
Another type of user input device is cursor control 116, such as a mouse, a trackball, or 
cursor direction keys for communicating direction information and command selections 
to processor 104 and for controlling cursor movement on display 112. This input device 
typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis 
(e.g., y), that allows the device to specify positions in a plane." From line 55 of column 
8, "When the instrumented code have been compiled into memory management or 
other library routines of the program under a debugging switch, the programmer is now 
ready to diagnose the cause of the memory corruption. Preferably, the following steps 
are performed within a symbolic debugger such as sdb (a standard UNIX.TM. 
debugger) or gdb (a freeware debugger), but some of the steps may optionally be 
performed by hard coding some additional code into the program and recompiling.") 
configured (i) to present said command input in response to one or more user input 
parameters and (ii) to display said debug information (From line 31 of column 8, "If 
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equal, the memory allocation routine would then call a debugging function. The 
debugging function need not do anything at all and can be a stub function that merely 
returns back to the calling function as long as the debugging function allows for a 
breakpoint to be set in the debugger. In some embodiments, however, the debugging 
function can also output useful information, such as the address, type, and value of the 
object to the screen or to a log file. In addition, a separate debugging routine may be 
provided for each of the memory management routines." From line 10 of column 9, 
"When the breakpoint is triggered (e.g. when a memory management routine handles 
an object with the address set in the global debug pointer), the debugger breaks 
execution of the problem, allowing the programmer to issue debugging commands to 
inspect memory locations and continue the program's running from the breakpoint. For 
example, when the memory allocation routine allocates memory for an object that starts 
with the address set in the global debug pointer, then the debugging routine would be 
called, triggering the breakpoint and suspending execution of the program within the 
debugger." From line 31 of column 8, "If equal, the memory allocation routine would 
then call a debugging function. The debugging function need not do anything at all and 
can be a stub function that merely returns back to the calling function as long as the 
debugging function allows for a breakpoint to be set in the debugger. In some 
embodiments, however, the debugging function can also output useful information, such 
as the address, type, and value of the object to the screen or to a log file. In addition, a 
separate debugging routine may be provided for each of the memory management 
routines." From line 30 of column 9, "At block 208, e.g. after the last breakpoint is 
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triggered, a watchpoint is set to detect changes to the memory location that is being 
corrupted. Alternatively, the memory location can be manually inspected by single 
stepping through the program. After setting the watchpoint, execution of the program is 
continued until the watchpoint is triggered, which occurs upon a change to the corrupted 
memory location, thereby breaking execution of the program. At each of the breaks in 
execution due to encountering the watchpoints, the programmer can use the debugger 
to inspect the program and data in search of the cause of the memory corruption. If the 
programmer does indeed concluded that the latest watchpoint detected the actual 
corruption, rather than an intended use of the memory location, then the programmer 
can tell from the current program counter in the debugger which statement caused the 
corruption."). 

21 . Referring to claim 1 8, Sexton discloses displaying said retrieved one or more 
accesses and said retrieved one or more types of debug information using a graphic 
user interface (From line 55 of column 5, "Computer system 100 may be coupled via 
bus 102 to a display 112, such as a cathode ray tube (CRT), for displaying information 
to a computer user. An input device 114, including alphanumeric and other keys, is 
coupled to bus 102 for communicating information and command selections to 
processor 104. Another type of user input device is cursor control 116, such as a 
mouse, a trackball, or cursor direction keys for communicating direction information and 
command selections to processor 104 and for controlling cursor movement on display 
112. This input device typically has two degrees of freedom in two axes, a first axis 
(e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a 
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plane." From line 55 of column 8, "When the instrumented code have been compiled 
into memory management or other library routines of the program under a debugging 
switch, the programmer is now ready to diagnose the cause of the memory corruption. 
Preferably, the following steps are performed within a symbolic debugger such as sdb 
(a standard UNIX.TM. debugger) or gdb (a freeware debugger), but some of the steps 
may optionally be performed by hard coding some additional code into the program and 
recompiling.") configured (i) to present said command input in response to one or more 
user input parameters and (ii) to display said debug information (From line 31 of column 
8, "If equal, the memory allocation routine would then call a debugging function. The 
debugging function need not do anything at all and can be a stub function that merely 
returns back to the calling function as long as the debugging function allows for a 
breakpoint to be set in the debugger. In some embodiments, however, the debugging 
function can also output useful information, such as the address, type, and value of the 
object to the screen or to a log file. In addition, a separate debugging routine may be 
provided for each of the memory management routines." From line 10 of column 9, 
"When the breakpoint is triggered (e.g. when a memory management routine handles 
an object with the address set in the global debug pointer), the debugger breaks 
execution of the problem, allowing the programmer to issue debugging commands to 
inspect memory locations and continue the program's running from the breakpoint. For 
example, when the memory allocation routine allocates memory for an object that starts 
with the address set in the global debug pointer, then the debugging routine would be 
called, triggering the breakpoint and suspending execution of the program within the 
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debugger." From line 31 of column 8, "If equal, the memory allocation routine would 
then call a debugging function. The debugging function need not do anything at all and 
can be a stub function that merely returns back to the calling function as long as the 
debugging function allows for a breakpoint to be set in the debugger. In some 
embodiments, however, the debugging function can also output useful information, such 
as the address, type, and value of the object to the screen or to a log file. In addition, a 
separate debugging routine may be provided for each of the memory management 
routines." From line 30 of column 9, "At block 208, e.g. after the last breakpoint is 
triggered, a watchpoint is set to detect changes to the memory location that is being 
corrupted. Alternatively, the memory location can be manually inspected by single 
stepping through the program. After setting the watchpoint, execution of the program is 
continued until the watchpoint is triggered, which occurs upon a change to the corrupted 
memory location, thereby breaking execution of the program. At each of the breaks in 
execution due to encountering the watchpoints, the programmer can use the debugger 
to inspect the program and data in search of the cause of the memory corruption. If the 
programmer does indeed concluded that the latest watchpoint detected the actual 
corruption, rather than an intended use of the memory location, then the programmer 
can tell from the current program counter in the debugger which statement caused the 
corruption."). 

22. Referring to claim 19, Sexton discloses modifying information displayed using 
said graphic user interface in response to one or more filter commands (From line 55 of 
column 5, "Computer system 100 may be coupled via bus 102 to a display 112, such as 
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a cathode ray tube (CRT), for displaying information to a computer user. An input device 
114, including alphanumeric and other keys, is coupled to bus 102 for communicating 
information and command selections to processor 104. Another type of user input 
device is cursor control 116, such as a mouse, a trackball, or cursor direction keys for 
communicating direction information and command selections to processor 104 and for 
controlling cursor movement on display 112. This input device typically has two degrees 
of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the 
device to specify positions in a plane." From line 55 of column 8, "When the 
instrumented code have been compiled into memory management or other library 
routines of the program under a debugging switch, the programmer is now ready to 
diagnose the cause of the memory corruption. Preferably, the following steps are 
performed within a symbolic debugger such as sdb (a standard UNIX.TM. debugger) or 
gdb (a freeware debugger), but some of the steps may optionally be performed by hard 
coding some additional code into the program and recompiling.") configured (i) to 
present said command input in response to one or more user input parameters and (ii) 
to display said debug information (From line 31 of column 8, "If equal, the memory 
allocation routine would then call a debugging function. The debugging function need 
not do anything at all and can be a stub function that merely returns back to the calling 
function as long as the debugging function allows for a breakpoint to be set in the 
debugger. In some embodiments, however, the debugging function can also output 
useful information, such as the address, type, and value of the object to the screen or to 
a log file. In addition, a separate debugging routine may be provided for each of the 
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memory management routines." From line 10 of column 9, "When the breakpoint is 
triggered (e.g. when a memory management routine handles an object with the address 
set in the global debug pointer), the debugger breaks execution of the problem, allowing 
the programmer to issue debugging commands to inspect memory locations and 
continue the program's running from the breakpoint. For example, when the memory 
allocation routine allocates memory for an object that starts with the address set in the 
global debug pointer, then the debugging routine would be called, triggering the 
breakpoint and suspending execution of the program within the debugger." From line 31 
of column 8, "If equal, the memory allocation routine would then call a debugging 
function. The debugging function need not do anything at all and can be a stub function 
that merely returns back to the calling function as long as the debugging function allows 
for a breakpoint to be set in the debugger. In some embodiments, however, the 
debugging function can also output useful information, such as the address, type, and 
value of the object to the screen or to a log file. In addition, a separate debugging 
routine may be provided for each of the memory management routines." From line 30 of 
column 9, "At block 208, e.g. after the last breakpoint is triggered, a watchpoint is set to 
detect changes to the memory location that is being corrupted. Alternatively, the 
memory location can be manually inspected by single stepping through the program. 
After setting the watchpoint, execution of the program is continued until the watchpoint 
is triggered, which occurs upon a change to the corrupted memory location, thereby 
breaking execution of the program. At each of the breaks in execution due to 
encountering the watchpoints, the programmer can use the debugger to inspect the 
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program and data in search of the cause of the memory corruption. If the programmer 
does indeed concluded that the latest watchpoint detected the actual corruption, rather 
than an intended use of the memory location, then the programmer can tell from the 
current program counter in the debugger which statement caused the corruption."). 

23. Claim 11,13 rejected under 35 U.S.C. 103(a) as being unpatentable over US 
6769116 to Sexton in view of 6052524 to Pauna as applied to claim 10 above, and 
further in view of "assembly code". 

24. Referring to claim 1 1 , Sexton discloses said one or more types of debug 
information comprise one or more instruction codes (From line 30 of column 9 (with 
emphasis), "At block 208, e.g. after the last breakpoint is triggered, a watchpoint is set 
to detect changes to the memory location that is being corrupted. Alternatively, the 
memory location can be manually inspected by single stepping through the program. 
After setting the watchpoint, execution of the program is continued until the watchpoint 
is triggered, which occurs upon a change to the corrupted memory location, thereby 
breaking execution of the program. At each of the breaks in execution due to 
encountering the watchpoints, the programmer can use the debugger to inspect the 
program and data in search of the cause of the memory corruption. If the programmer 
does indeed concluded that the latest watchpoint detected the actual corruption, rather 
than an intended use of the memory location, then the programmer can tell from the 
current program counter in the debugger which statement caused the corruption."). 

Although Sexton does not specifically disclose this instruction code may be 
assembler instruction code, assembly code is very well known in the art. Examiner 
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takes official notice for "assembly code". A person of ordinary skill in the art at the time 
of the invention would have been motivated to use assembly because it is faster than 
programming in machine code and provides efficient control over processor operations. 
25. Referring to claim 1 3, Sexton discloses said one or more types of debug 
information comprise a program flow leading to said one or more assembler instruction 
codes (Sexton, from line 31 of column 8, "If equal, the memory allocation routine would 
then call a debugging function. The debugging function need not do anything at all and 
can be a stub function that merely returns back to the calling function as long as the 
debugging function allows for a breakpoint to be set in the debugger. In some 
embodiments, however, the debugging function can also output useful information, such 
as the address, type, and value of the object to the screen or to a log file. In addition, a 
separate debugging routine may be provided for each of the memory management 
routines." Sexton, from line 30 of column 9, "At block 208, e.g. after the last breakpoint 
is triggered, a watchpoint is set to detect changes to the memory location that is being 
corrupted. Alternatively, the memory location can be manually inspected by single 
stepping through the program. After setting the watchpoint, execution of the program is 
continued until the watchpoint is triggered, which occurs upon a change to the corrupted 
memory location, thereby breaking execution of the program. At each of the breaks in 
execution due to encountering the watchpoints, the programmer can use the debugger 
to inspect the program and data in search of the cause of the memory corruption. If the 
programmer does indeed concluded that the latest watchpoint detected the actual 
corruption, rather than an intended use of the memory location, then the programmer 
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can tell from the current program counter in the debugger which statement caused the 
corruption."). 

Conclusion 

26. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. See notice of references cited. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Gabriel L. Chu whose telephone number is (571 ) 272- 
3656. The examiner can normally be reached on weekdays between 8:30 AM and 5:00 
PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Scott Baderman can be reached on (571) 272-3644. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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